Loading

×Sorry to interrupt
This page has an error. You might just need to refresh it.
[NoErrorObjectAvailable] Uncaught ReferenceError: addCTracking is not defined
Failing descriptor: {markup://c:KM_ArticleThemeLayout}

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Few NICs are down with error "[vmnicX : 0x45021b04c000] Failed to bring up link" (76656)

Last Updated: 2/27/2024Categories: TroubleshootingTotal Views: 26684Language:
Chinese (Simplified)JapaneseEnglish

4 like this article

Subscribe to get an email
newsletter with new updates

4 people found this helpful Please provide article feedback:

Symptoms

Few NICs are down with error "[vmnicX : 0x45021b04c000] Failed to bring up link"

Below are the logs you will see in vmkernel.log

2019-12-12T07:20:16.859Z cpu9:2101844 opID=76c0261e)Uplink: 16283: Setting speed/duplex to (25000 FULL) on vmnic4.
2019-12-12T07:20:16.859Z cpu3:2097412)bnxtnet: bnxtnet_linkstatus_set:2288: [vmnic4 : 0x45021b04c000] Bringing up link
2019-12-12T07:20:16.972Z cpu3:2097412)WARNING: bnxtnet: alloc_rx_buffers:1441: [vmnic4 : 0x45021b04c000] Failed to allocate all, init'ed rx ring 12 with 2973/3069 pages only
2019-12-12T07:20:16.976Z cpu3:2097412)WARNING: bnxtnet: bnxtnet_create_defq_group:279: [vmnic4 : 0x45021b04c000] failed to allocate queue group resource for defq
2019-12-12T07:20:16.978Z cpu3:2097412)WARNING: bnxtnet: bnxtnet_uplink_activate_dev:2050: [vmnic4 : 0x45021b04c000] failed to create default queue (Out of memory)
2019-12-12T07:20:16.978Z cpu3:2097412)WARNING: bnxtnet: bnxtnet_linkstatus_set:2291: [vmnic4 : 0x45021b04c000] Failed to bring up link
2019-12-12T07:20:16.978Z cpu9:2101844 opID=76c0261e)Uplink: 16302: Wait for device vmnic4 async call failed.
2019-12-12T07:24:33.719Z cpu31:2101845 opID=608326ea)Uplink: 16277: Setting link down on physical adapter vmnic4.
2019-12-12T07:24:33.719Z cpu45:2097412)bnxtnet: bnxtnet_linkstatus_set:2259: [vmnic4 : 0x45021b04c000] Taking down link
2019-12-12T07:24:41.921Z cpu50:2102458 opID=d2b86853)Uplink: 16283: Setting speed/duplex to (0 AUTO) on vmnic4.
2019-12-12T07:24:41.921Z cpu37:2097412)bnxtnet: bnxtnet_linkstatus_set:2288: [vmnic4 : 0x45021b04c000] Bringing up link
2019-12-12T07:24:42.017Z cpu66:2097412)WARNING: bnxtnet: alloc_rx_buffers:1441: [vmnic4 : 0x45021b04c000] Failed to allocate all, init'ed rx ring 12 with 2973/3069 pages only
2019-12-12T07:24:42.021Z cpu66:2097412)WARNING: bnxtnet: bnxtnet_create_defq_group:279: [vmnic4 : 0x45021b04c000] failed to allocate queue group resource for defq
2019-12-12T07:24:42.023Z cpu66:2097412)WARNING: bnxtnet: bnxtnet_uplink_activate_dev:2050: [vmnic4 : 0x45021b04c000] failed to create default queue (Out of memory)
2019-12-12T07:24:42.023Z cpu66:2097412)WARNING: bnxtnet: bnxtnet_linkstatus_set:2291: [vmnic4 : 0x45021b04c000] Failed to bring up link
2019-12-12T07:24:42.023Z cpu50:2102458 opID=d2b86853)Uplink: 16302: Wait for device vmnic4 async call failed.

vSAN Environments

vSAN nodes become network partitioned

Object storage policy status remains out of compliance due to delays in resync traffic completion.

Unresponsive vSAN nodes due to Storage IO processing delays

VM production affected due to Storage IO processing delays

Purpose

This article is to provide the information to troubleshoot issue where everything is fine from the hardware end.

Cause

The cause of the NIC to be down is due to the fact that the ESXI host has a default limit for how much the rx queues can grow i.e.  32 queues.

If the NICs are using MTU 9000 and are of higher bandwidth, this queue can be utilised with few NICs and any NICs after that will fail to get the queue and driver will mark it as down.

Previously the value of  netPagePoolLimitCap is 98304

98304 / 3069 = 32.  That's to say, if a host uses bnxtnet driver(as an example), it can only globally support 32 rx queues at most when jumbo frame is enabled no matter there are how many nic adapters.

Impact / Risks

The NICs will be marked as down.

Resolution

This value was changed in ESXi 7.0 u1

Workaround

Since this is a default value you can increase the value by running the below commands,

esxcli system settings kernel set -s netPagePoolLimitCap -v 1048576

The following commands can be used to verify the value,

esxcli system settings kernel list -o netPagePoolLimitCap
Name                 Type    Configured  Runtime  Default  Description
-------------------  ------  ----------  -------  -------  -----------
netPagePoolLimitCap  uint32  1048576       1048576    98304    Maximum number of pages period for the packet page pool.

Reboot the ESXi host.

Or
You can reduce the MTU to 1500 if customer doesn't agree to implement the above commands.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Additional Resources

KB
•
削除されたクラスタ ノードの構成の残りをクリーンアップする (76662)

KB
•
ライセンスのアップグレード後に、vRA Code Stream サービスがユーザー インターフェイスに表示されない (76642)

KB
•
vRealize Automation 仮想アプライアンスとは異なるドメインの Kerberos の設定 (76634)

KB
•
由于 vCenter Server 部署期间 CEIP 设置不匹配，VMware Directory Service (VMDIRD) 进入不可恢复的状态 (76646)

Results 1-4 of 4

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSphere ESXi

Related Versions:

VMware vSphere ESXi 6.7

VMware vSphere ESXi 6.5

VMware vSphere ESXi 6.0

Take Our Survey

Support Assistant